home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / comm / tcp / AmiTCPtnserv.lha / tnserv / rfc857.txt < prev    next >
Text File  |  1995-01-15  |  11KB  |  285 lines
  1.  
  2. Network Working Group                                          J. Postel
  3. Request for Comments: 857                                    J. Reynolds
  4.                                                                      ISI
  5. Obsoletes: NIC 15390                                            May 1983
  6.  
  7.                            TELNET ECHO OPTION
  8.  
  9.  
  10. This RFC specifies a standard for the ARPA Internet community.  Hosts on
  11. the ARPA Internet are expected to adopt and implement this standard.
  12.  
  13. 1. Command Name and Code
  14.  
  15.    ECHO       1
  16.  
  17. 2. Command Meanings
  18.  
  19.    IAC WILL ECHO
  20.  
  21.       The sender of this command REQUESTS to begin, or confirms that it
  22.       will now begin, echoing data characters it receives over the
  23.       TELNET connection back to the sender of the data characters.
  24.  
  25.    IAC WON'T ECHO
  26.  
  27.       The sender of this command DEMANDS to stop, or refuses to start,
  28.       echoing the data characters it receives over the TELNET connection
  29.       back to the sender of the data characters.
  30.  
  31.    IAC DO ECHO
  32.  
  33.       The sender of this command REQUESTS that the receiver of this
  34.       command begin echoing, or confirms that the receiver of this
  35.       command is expected to echo, data characters it receives over the
  36.       TELNET connection back to the sender.
  37.  
  38.    IAC DON'T ECHO
  39.  
  40.       The sender of this command DEMANDS the receiver of this command
  41.       stop, or not start, echoing data characters it receives over the
  42.       TELNET connection.
  43.  
  44. 3. Default
  45.  
  46.    WON'T ECHO
  47.  
  48.    DON'T ECHO
  49.  
  50.       No echoing is done over the TELNET connection.
  51.  
  52. 4. Motivation for the Option
  53.  
  54.  
  55. Postel & Reynolds                                               [Page 1]
  56.  
  57.  
  58.  
  59. RFC 857                                                         May 1983
  60.  
  61.  
  62.    The NVT has a printer and a keyboard which are nominally
  63.    interconnected so that "echoes" need never traverse the network; that
  64.    is to say, the NVT nominally operates in a mode where characters
  65.    typed on the keyboard are (by some means) locally turned around and
  66.    printed on the printer.  In highly interactive situations it is
  67.    appropriate for the remote process (command language interpreter,
  68.    etc.) to which the characters are being sent to control the way they
  69.    are echoed on the printer.  In order to support such interactive
  70.    situations, it is necessary that there be a TELNET option to allow
  71.    the parties at the two ends of the TELNET connection to agree that
  72.    characters typed on an NVT keyboard are to be echoed by the party at
  73.    the other end of the TELNET connection.
  74.  
  75. 5. Description of the Option
  76.  
  77.    When the echoing option is in effect, the party at the end performing
  78.    the echoing is expected to transmit (echo) data characters it
  79.    receives back to the sender of the data characters.  The option does
  80.    not require that the characters echoed be exactly the characters
  81.    received (for example, a number of systems echo the ASCII ESC
  82.    character with something other than the ESC character).  When the
  83.    echoing option is not in effect, the receiver of data characters
  84.    should not echo them back to the sender; this, of course, does not
  85.    prevent the receiver from responding to data characters received.
  86.  
  87.    The normal TELNET connection is two way.  That is, data flows in each
  88.    direction on the connection independently; and neither, either, or
  89.    both directions may be operating simultaneously in echo mode.  There
  90.    are five reasonable modes of operation for echoing on a connection
  91.    pair:
  92.  
  93.       
  94.                 <----------------
  95.       
  96.       Process 1                   Process 2
  97.                 ---------------->
  98.                  Neither end echoes
  99.  
  100.       
  101.                 <----------------
  102.                    \
  103.       Process 1    /              Process 2
  104.                 ---------------->
  105.              One end echoes for itself
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Postel & Reynolds                                               [Page 2]
  113.  
  114.  
  115.  
  116. RFC 857                                                         May 1983
  117.  
  118.  
  119.       
  120.                 <----------------
  121.                              \
  122.       Process 1              /    Process 2
  123.                 ---------------->
  124.           One end echoes for the other
  125.  
  126.       
  127.                 <----------------
  128.                    \         /
  129.       Process 1    /         \    Process 2
  130.                 ---------------->
  131.           Both ends echo for themselves
  132.  
  133.       
  134.                 <----------------
  135.                    \ /
  136.       Process 1    / \            Process 2
  137.                 ---------------->
  138.            One end echoes for both ends
  139.  
  140.    This option provides the capability to decide on whether or not
  141.    either end will echo for the other.  It does not, however, provide
  142.    any control over whether or not an end echoes for itself;  this
  143.    decision must be left to the sole discretion of the systems at each
  144.    end (although they may use information regarding the state of
  145.    "remote" echoing negotiations in making this decision).
  146.  
  147.    It should be noted that if BOTH hosts enter the mode of echoing
  148.    characters transmitted by the other host, then any character
  149.    transmitted in either direction will be "echoed" back and forth
  150.    indefinitely.  Therefore, care should be taken in each implementation
  151.    that if one site is echoing, echoing is not permitted to be turned on
  152.    at the other.
  153.  
  154.    As discussed in the TELNET Protocol Specification, both parties to a
  155.    full-duplex TELNET connection initially assume each direction of the
  156.    connection is being operated in the default mode which is non-echo
  157.    (non-echo is not using this option, and the same as DON'T ECHO, WON'T
  158.    ECHO).
  159.  
  160.    If either party desires himself to echo characters to the other party
  161.    or for the other party to echo characters to him, that party gives
  162.    the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes)
  163.    for acceptance of the option.  If the request to operate the
  164.    connection in echo mode is refused, then the connection continues to
  165.    operate in non-echo mode.  If the request to operate the connection
  166.    in echo mode is accepted, the connection is operated in echo mode.
  167.  
  168.  
  169. Postel & Reynolds                                               [Page 3]
  170.  
  171.  
  172.  
  173. RFC 857                                                         May 1983
  174.  
  175.  
  176.    After a connection has been changed to echo mode, either party may
  177.    demand that it revert to non-echo mode by giving the appropriate
  178.    DON'T ECHO or WON'T ECHO command (which the other party must confirm
  179.    thereby allowing the connection to operate in non-echo mode).  Just
  180.    as each direction of the TELNET connection may be put in remote
  181.    echoing mode independently, each direction of the TELNET connection
  182.    must be removed from remote echoing mode separately.
  183.  
  184.    Implementations of the echo option, as implementations of all other
  185.    TELNET options, must follow the loop preventing rules given in the
  186.    General Considerations section of the TELNET Protocol Specification.
  187.    Also, so that switches between echo and non-echo mode can be made
  188.    with minimal confusion (momentary double echoing, etc.), switches in
  189.    mode of operation should be made at times precisely coordinated with
  190.    the reception and transmission of echo requests and demands.  For
  191.    instance, if one party responds to a DO ECHO with a WILL ECHO, all
  192.    data characters received after the DO ECHO should be echoed and the
  193.    WILL ECHO should immediately precede the first of the echoed
  194.    characters.
  195.  
  196.    The echoing option alone will normally not be sufficient to effect
  197.    what is commonly understood to be remote computer echoing of
  198.    characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD option
  199.    will normally have to be invoked in conjunction with the ECHO option
  200.    to effect character-at-a-time remote echoing.
  201.  
  202. 6. A Sample Implementation of the Option
  203.  
  204.    The following is a description of a possible implementation for a
  205.    simple user system called "UHOST".
  206.  
  207.    A possible implementation could be that for each user terminal, the
  208.    UHOST would keep three state bits: whether the terminal echoes for
  209.    itself (UHOST ECHO always) or not (ECHO mode possible), whether the
  210.    (human) user prefers to operate in ECHO mode or in non-ECHO mode, and
  211.    whether the connection from this terminal to the server is in ECHO or
  212.    non-ECHO mode.  We will call these three bits P(hysical), D(esired),
  213.    and A(ctual).
  214.  
  215.    When a terminal dials up the UHOST the P-bit is set appropriately,
  216.    the D-bit is set equal to it, and the A-bit is set to non-ECHO.  The
  217.    P-bit and D-bit may be manually reset by direct commands if the user
  218.    so desires.  For example, a user in Hawaii on a "full-duplex"
  219.    terminal, would choose not to operate in ECHO mode, regardless of the
  220.    preference of a mainland server.  He should direct the UHOST to
  221.    change his D-bit from ECHO to non-ECHO.
  222.  
  223.    When a connection is opened from the UHOST terminal to a server, the
  224.  
  225.  
  226. Postel & Reynolds                                               [Page 4]
  227.  
  228.  
  229.  
  230. RFC 857                                                         May 1983
  231.  
  232.  
  233.    UHOST would send the server a DO ECHO command if the MIN (with
  234.    non-ECHO less than ECHO) of the P- and D-bits is different from the
  235.    A-bit.  If a WON'T ECHO or WILL ECHO arrives from the server, the
  236.    UHOST will set the A-bit to the MIN of the received request, the
  237.    P-bit, and the D-bit.  If this changes the state of the A-bit, the
  238.    UHOST will send off the appropriate acknowledgment; if it does not,
  239.    then the UHOST will send off the appropriate refusal if not changing
  240.    meant that it had to deny the request (i.e., the MIN of the P-and
  241.    D-bits was less than the received A-request).
  242.  
  243.    If while a connection is open, the UHOST terminal user changes either
  244.    the P-bit or D-bit, the UHOST will repeat the above tests and send
  245.    off a DO ECHO or DON'T ECHO, if necessary.  When the connection is
  246.    closed, the UHOST would reset the A-bit to indicate UHOST echoing.
  247.  
  248.    While the UHOST's implementation would not involve DO ECHO or DON'T
  249.    ECHO commands being sent to the server except when the connection is
  250.    opened or the user explicitly changes his echoing mode, bigger hosts
  251.    might invoke such mode switches quite frequently.  For instance,
  252.    while a line-at-a-time system were running, the server might attempt
  253.    to put the user in local echo mode by sending the WON'T ECHO command
  254.    to the user; but while a character-at-a-time system were running, the
  255.    server might attempt to invoke remote echoing for the user by sending
  256.    the WILL ECHO command to the user.  Furthermore, while the UHOST will
  257.    never send a WILL ECHO command and will only send a WON'T ECHO to
  258.    refuse a server sent DO ECHO command, a server host might often send
  259.    the WILL and WON'T ECHO commands.
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283. Postel & Reynolds                                               [Page 5]
  284.  
  285.